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Description 

The present invention is related generally to digital 
computers, and more specifically to a system and meth- 
od for executing application programs over a distributed 
network. 

As small computers continue to become more pow- 
erful and their costs decrease, networks of computers 
continue to become more common. These networks can 
be connected using a variety of network architectures, 
and typically consist of a moderate to large number of 
nodes. Each node can be a stand alone computer sys- 
tem, or a network shared resource such as a file server 
or printer. 

In some networks, it is common for a user at one 
node to wish to execute a program or access data which 
resides on another node. Such execution or access can 
be accomplished in several different ways. The user can 
copy the necessary files from the remote node to his 
own local node, and process them locally. It is also pos- 
sible to have the local node, typically a workstation or 
desktop computer, emulate a simple terminal, and ac- 
cess the remote node. Under the second arrangement, 
commands are entered from, and results displayed on, 
the local node, while all processing takes place on the 
remote node. 

A third technique is to execute an applications pro- 
gram on the local node which communicates to the re- 
mote node in a manner transparent tothe user. The local 
applications program can send commands to the re- 
mote node in order to access data or cause execution 
of programs on the remote node. 

The techniques just described have several limita- 
tions and drawbacks. The technique of copying data and 
programs to a local node ; not in general use on sophis- 
ticated networks, spends large amounts of time copying 
files which may be quite large in comparison to the 
amount of data actually needed. Also ; creating multiple 
copies of files introduces a serious data coherency prob- 
lem, in that it is difficult to reflect updates to a central 
location in a timely manner. 

Usingalocal node to emulateasimpleterminal min- 
imizes the copying large files from one node to another, 
but still uses a fairly large share of network communica- 
tion resources. Everything typed at the local terminal, 
and everything displayed thereon, requires transmis- 
sion of information over the network. Using an applica- 
tions program running on the local node to interface with 
a user and send encoded commands to the remote node 
can decrease the amount of information transmitted, but 
does not entirely eliminate the problem. 

For example, it is common for a central database to 
be connected to a network for access by the other 
nodes. The database can be access with special com- 
mands, such as those used in a Structured Query Lan- 
guage (SQL). Each SQL statement defines a single re- 
quest to the database. As used herein, a transaction is 
an integral piece of work which, when completed, is 
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committed to the database. All changes to the database 
are tentative until committed, so that an integrated trans- 
action can be rolled back, leaving the database in the 
same state it was before the transaction began. A series 

5 of database requests are generally needed to perform 
a single transaction. 

IBM Systems Journal 27 (1988) No 3 pp 362 - 369 
describes a system in which SQL database requests 
can be executed remotely by sending messages repre- 

70 senting the requests over a communications network 
from an application running on a local machine to a data 
base management system on a remote machine. 

When an application is running on a local node, and 
communicating with a database manager on a remote, 

15 or server node, each request in a transaction requires 
two communications over the network. The database re- 
quest must first be transmitted from the local node to the 
database server, and the results must be returned to the 
local node. Thus ; if a single transaction requires 7 da- 

20 tabase requests, 14 separate messages must be com- 
municated over the communications network. 

Viewed from a first aspect the invention provides a 
method for executing a transaction between a local net- 
work node and a remote node in a distributed database 

25 system, the local network node having a user interface 
facility and the remote node having a database manager 
for a remote database accessible through the remote 
node, the method comprising the steps of: enabling, via 
the user interface facility a user to initiate a transaction; 

30 requiring, via the user interface facility, the user to enter 
items of information necessary for a series of requests 
defining the transaction; transmitting from the local net- 
work node over a network communications link to the 
remote node, as a single message, the information 

35 items specified by the user; responsive to receipt of the 
single message at the remote node, making a series of 
individual database requests through the database 
manager using the transmitted information items to gen- 
erate a transaction result; and returning the transaction 

40 result to the local network node as a second single mes- 
sage over the communications link. 

In preferred embodiments of the invention a system 
suitable for use on a computer network provides a user 
interface on a local node and an application to be run 

45 on a remote node. An application for accepting input 
from the user and translating it to appropriate com- 
mands for the remote application is divided, and located 
partially on the local node and partially on the remote 
node. That portion located on the local node gathers any 

50 information required from the user and transmits it to the 
portion located on the remote node in an efficient man- 
ner. The remote location portion uses the transmitted 
information to interface with the remote application and 
obtain results. The results are collected and transmitted 

55 to the local portion, from which they are returned to the 
user. 

Viewed from a second aspect the invention pro- 
vides a distributed database system in which a transac- 
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tion can be executed between a local network node and 
a remote node ; the local network node having a user 
interface facility and the remote node having a database 
manager for a remote database accessible through the 
remote node, the local network node comprising: means 
for enabling, via the user interface facility, a user to ini- 
tiate a transaction; means for requiring, via the user in- 
terface facility, the user to enter items of information nec- 
essary for a series of requests defining the transaction; 
means to transmit from the local network node over a 
network communications link to the remote node, as a 
single message, the information items specified by the 
user: the remote node comprising: means responsive to 
receipt of the single message for making a series of in- 
dividual database requests through the database man- 
ager using the transmitted information items to generate 
a transaction result; and means for returning the trans- 
action result to the local network node as a second sin- 
gle message over the communications link. 

An embodiment of the invention will now be de- 
scribed, by way of example only, with reference to the 
accompanying drawings in which: 

FIGURE 1 is a block diagram of a system according 
one embodiment of the present invention; 

FIGURE 2 is a flowchart of a method for making da- 
tabase accesses in accordance with the system of 
Figure 1; and 

FIGURES 3 and 4 illustrate data structures suitable 
for use with the method of Figure 2 

The preferred embodiment is described in terms of 
a system and method for remotely accessing a data- 
base over a network. As will be described below, the 
precise nature of the database and software for directly 
manipulating that database do not form a part of the 
present invention. However, the preferred embodiment 
will be described in relation to a database manager 
which accepts requests using a Structured Query Lan- 
guage (SQL) such as is available from International 
Business Machines Corporation. 

Referring to Figure 1 , a system for making remote 
database accesses includes a user interface 10. The in- 
terface, typically including a display, keyboard, mouse 
or other pointing device, and software to drive these de- 
vices, is in communication with a user application (inter- 
face portion) 12. The interface portion 12 includes soft- 
ware for accepting input from the user interface 10 and 
directing output thereto. Typically, a computer system 
on a network will have a single user interface 10, with 
multiple user applications 12 which can be invoked by 
the user. 

A remote data services software utility 14 can be 
invoked by the interface portion 12, generally through a 
procedure call. The remote data services 1 4, in turn, can 
invoke, via a procedure call, either a user application 



(server portion) 16 or a communications interface utility 
18. As is described below, the server portion 16 gener- 
ates calls to a local database manager 20, and accepts 
results returned therefrom. The database manager 20 

5 accepts requests from the server portion 16 in a prede- 
termined format, such as SQL requests, and performs 
reads and updates on a database. The details of the da- 
tabase and the database manager 20 do not form a part 
of the present invention. SQL database managers are 

70 commonly available, and many of these can be used 
with the present invention with little or no modification. 

The communications interface utility 1 8 connects to 
a network represented by communications line 22. A 
large number of other devices may be connected to the 

15 network as indicated by communication lines 24, and 
one node in particular is connected through communi- 
cations line 26 which is attached to a communications 
interface 28. The type of network used does not form a 
part of the present invention, and the communications 

20 interfaces 1 8, 28 are simply those which are appropriate 
to a given network environment. Many different com- 
monly available network protocols are suitable for use 
with the present invention. 

At the remote node, a remote data services soft- 

25 ware utility 30 communicates with communications in- 
terface 28. The remote data services utility 30 also com- 
municates with a user application (server portion) 32, 
which in turn makes database requests to a database 
manager 34. The communications between and opera- 
te tions of items 30, 32, and 34 is similar to that of items 
14, 16, and 20. 

Figure 2 is a flowchart illustrating the sequence of 
events which occur when a user at the local node un- 
dertakes to perform a transaction on the database. As 

35 described above, a transaction is a sequence of individ- 
ual database requests, with any changes to the data- 
base being committed only when the transaction has 
been successfully completed. Thus, the sequence of 
database requests making up a single transaction can 

40 be considered as a whole, with all the elements thereof 
completing successfully, or failing, together. Any up- 
dates made to the database do not actually take effect 
until the transaction commits. 

Referring to Figure 2, when a user initiates a trans- 

45 action, the interface portion of the user application gath- 
ers all of the required information from the user 40. The 
interface portion of the application may require the user 
to enter several items of information in response to in- 
dividual queries, the user may be required to fill in blanks 

50 on a template, or other techniques known in the art may 
be used. Once all of the information necessary for the 
transaction has been gathered, it is formatted into a 
standard format 42 as will be described below. At this 
time, the interface portion 12 makes a procedure call to 

55 the remote data services utility 14 and passes the for- 
matted information thereto. 

The services utility 14 first determines whether the 
database against which the transaction is to run is a lo- 
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cal or remote database 44. If the database is not local, 
the services utility 14 prepares the data for transmission 
over a network 46. This generally involves serializing 
what may be a complex data structure, including blocks 
of memory interconnected by pointers, into a "flat" struc- 
ture representative of the same relationships. The data 
is then sent to the appropriate remote node 48 by the 
communications interfaces 18, 28, and the formatted 
data is recreated 50 at the remote node by the data serv- 
ices utility 30 at that node. The recreated data is prefer- 
ably identical to the data formatted in step 42. 

The remote data services utility 30 then causes the 
server portion of the user application 32 to execute 52, 
and passes the formatted data to it. The server portion 
of the user application now has all of the data necessary 
to execute the entire transaction. Until this time, the ac- 
tual database requests which make up the transaction 
have not been considered by any part of the system. 
The code of the server portion 32 consists of a series of 
procedure calls to the database manager 34, using the 
data gathered from the user as input. These procedure 
calls are database requests 54, and control passes back 
and forth between the server portion of the user appli- 
cation 32 and the database manager 34. 

Once all of the database requests that make up a 
single transaction have been completed, the server por- 
tion of the user application 32 formats the results 56 and 
returns them to the services utility 30. A check is made 
to see if the accessed database was located on the 
same local node as the user 58, and if not the results 
are prepared for transmission 60 in the same manner 
as data was prepared for transmission in step 46. The 
data is then sent to the user node 62, and the formatted 
results are recreated 64 by the remote data services util- 
ity 14. The results are then returned to the user applica- 
tion 66, which performs local actions such as displaying 
the results to the user. 

If the database to be accessed is a local database, 
the server portion 16 and database manager 20 are in- 
voked on the local node rather than invoking the server 
portion 32 and database manager 34 on a remote node. 
The flow of control in Figure 2 determined by steps 44 
and 58 represents this situation. If the database is local 
to the user, the remote data services utility 14 invokes 
the server portion 16 directly, with no data preparation, 
transmission, or format recreation steps necessary. As 
far as the user interface 10 and interface portion 12 are 
concerned, the location of the server portion and data- 
base manager are not important; the information gath- 
ering and formatting steps 40, 42 are the same in either 
case. 

For a particular application, a database manager is 
invoked by only a single server portion of the user ap- 
plication. The server portion can be called by a user ap- 
plication interface portion running locally or by any 
number of such interface portions running on different 
network nodes. The only difference between users run- 
ning database transactions from a local node or remote 



nodes is that the remote data services utility 14 on the 
remote nodes cause data to be transmitted over the net- 
work instead of passed directly to the server portion 16. 
An example of the type of system which could ad- 

5 vantageously be designed in accordance with the above 
principles would be a network of automated teller ma- 
chines (ATM). A customer who wished to, for example, 
withdraw money from his account would initiate a trans- 
action at an ATM by identifying himself with a magneti- 
se cally coded card and a password. The card contains 
customer information such as bank identification and 
account number. The interface portion 12 requests the 
user to enter the amount of the transaction, and builds 
a data structure which generally includes at least the 

15 bank identification, account number, amount of transac- 
tion, and an identification of the ATM in use. This infor- 
mation is then transmitted to a central server holding the 
database. The server portion of the user application 32 
then uses this transmitted information to make a series 

20 of calls to the database. Such a series of calls might 
include : for example, locking the required resources at 
the beginning of the transaction, updating the custom- 
er's account balance, updating the bank account bal- 
ance, and updating the ATM account balance, and com- 

25 mitting the transaction, and releasing the locked re- 
sources. A result is returned indicating whether the 
transaction is successful, and this information is trans- 
mitted back to the ATM. If the transaction is successful, 
the money is dispensed to the customer. 

30 The example just described requires several calls 
to the database manager to perform various database 
functions. These include locking the necessary resourc- 
es, performingthe required updates, and committing the 
transaction. The program code to invoke these data- 

35 base requests is located in the server portion of the user 
application, so that the only information which need be 
transmitted over the network is the minimum amount of 
user information necessary for the transaction, and the 
results. 

40 Figure 2 illustrates the sequence of events utilized 
to perform a single transaction. Establishing a network 
communications link between the user node and the re- 
mote node is not shown. This link can be established 
once for a series of transactions, can be established per- 

45 manently, or may be established anew for each trans- 
action. The technique chosen will depend on the nature 
of the network and its topology. 

The preferred embodiment can also incorporate the 
features of the related European Published Patent Ap- 

50 plication No. entitled REMOTE INTERRUPT 
PROCESSING, a copy of which has been placed on the 
application file of the present invention. That application 
describes a technique for allowing the remote database 
manager to gracefully respond to an interrupt requested 

55 by the user. When a transaction is interrupted, prefera- 
bly only the currently executing request is cancelled and 
rolled back, and the transaction remains pending. This 
means that all resource locks remain in place. The entire 
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transaction is cancelled and rolled back only upon re- 
ceipt of an explicit command to do so after the above 
described interrupt. 

In order to rollback only the current request, a save- 
point, as known in the art is taken as each new request 
is begun, as well as at the beginning of the entire trans- 
action. Such partial rollback saves the time already in- 
vested in the completed requests if the transaction is 
restarted; only the time invested in a single request is 
lost. 

Figure 3 shows a data structure of the type created 
by the user application interface portion 12 and utilized 
by the server portion 32. Figure 3 shows a structure for 
IN_SQLDA, which is an input data structure containing 
information needed for SQL database accesses. The 
variables shown in Figure 3 are consistent with stand- 
ard usage which will be recognized by those skilled in 
the art. The first two entries, SQLDAID and SQLDABC 
contain an identification string and total byte count for 
the structure. SQLN gives the number of variables which 
are included in the structure ; and SQLD indicates how 
many of these are actually used. The entries SQLVAR 
[0] and SQLVAR[1] are pointers to data blocks contain- 
ing information about variables. Each data block 70, 72 
corresponds to 1 variable, and identifies that variable in 
a manner consistent with standard SQL usage. For ex- 
ample, the type and length of the variable are shown, 
and a pointer to the actual data itself is contained in each 
data block 70, 72. 

Figure 4 shows a data structure suitable for use for 
returning results as a variable OUT_SQLDA. This struc- 
ture is analogous to that shown in Figure 3. Both 
IN_SQLDA and OUT_SQLDA can contain different 
numbers of variables from those shown in Figures 3 
and 4, depending upon the requirements of the particu- 
lar application. 

When the database is located on a node remote 
from the user, the data structure shown in Figures 3 and 
4 must be "flattened" or "serialized" to a form suitable 
fortransmission over a network. This serialization is per- 
formed by the remote data services routines 1 4, 30. The 
precise format used for the communication over a net- 
work will depend upon the type of network being used, 
but will generally be a simple serial string of characters. 
As long as all of the remote data services utilities know 
what communications format is being used, the precise 
nature of the transmission format is not important. 

As will be recognized by those skilled in the art, the 
system and method described above minimize the 
amount of data which is transmitted over the network. 
The user application, which obtains data from the user 
and makes the necessary calls to the database, is di- 
vided into separate pieces in such a way as to allow for 
this minimum amount of communication. Obtaining user 
input, which can be time consuming given the relatively 
slow rate at which data is entered and the necessary 
validity checks which must be performed, is all accom- 
plished at the local node without burdening the commu- 



nications network. The process of performing database 
requests is all done at the server node at which the da- 
tabase is located. Use of the communications network 
is limited to identifying a transaction and passing pre- 

5 cisely the information needed by that transaction, and 
returning a result. 

It will be appreciated that in at least the described 
preferred embodiment the present invention provides 
for applications processing at a location remote from a 

70 user in such a manner as to minimize the amount of in- 
formation commun icated over a network so that only two 
messages need be communicated in order for multiple 
database access requests to be performed. 
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Claims 



1 . A method for executing a transaction between a lo- 
cal network node and a remote node in a distributed 
20 database system, the local network node having a 
user interface facility (10) and the remote node hav- 
ing a database manager (34) for a remote database 
accessible through the remote node, the method 
comprising the steps of: 

25 

enabling, via the user interface facility (10), a 
user to initiate a transaction; 



requiring, via the user interface facility (10), the 
user to enter items of information necessary for 
a series of requests defining the transaction; 

transmitting (48) from the local network node 
over a network communications link (22, 26) to 
the remote node, as a single message, the in- 
formation items specified by the user; 

responsive to receipt of the single message at 
the remote node, making (52, 54) a series of 
individual database requests through the data- 
base manager (34) using the transmitted infor- 
mation items to generate a transaction result; 

and returning (62) the transaction result to the 
local network node as a second single mes- 
sage over the communications link (22, 26). 



2. A method as claimed in claim 1 wherein the infor- 
mation items and the transaction result are format- 

so ted (42, 56) in a preselected manner prior to trans- 
mission over the network communications link and 
wherein the information items and the transaction 
result are restored (50, 64) upon receipt at the re- 
mote node and at the local node, respectively. 

55 

3. A method as claimed in claim 1 or claim 2 wherein 
the database manager is an SQL database manag- 
er and each of the database requests comprises an 
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SQL request. 

4. A distributed database system in which a transac- 
tion can be executed between a local network node 
and a remote node, the local network node having s 
a user interface facility (10) and the remote node 
having a database manager (34) for a remote data- 
base accessible through the remote node, the local 
network node comprising: 

w 

means tor enabling, via the user interface facil- 
ity (1 0), a user to initiate a transaction; 

means for requiring, via the user interface facil- 
ity (10), the user to enter items of information is 
necessary for a series of requests defining the 
transaction; 

means to transmit (48) from the local network 
node over a network communications link (22, 20 2. 
26) to the remote node ; as a single message, 
the information items specified by the user; 

the remote node comprising: 

25 

means responsive to receipt of the single mes- 
sage for making (52, 54) a series of individual 
database requests through the database man- 
ager (34) using the transmitted information 
items to generate a transaction result; 30 3. 

and means for returning (62) the transaction re- 
sult to the local network node as a second sin- 
gle message over the communications link (22, 
26). 35 4. 



Patentanspriiche 

1. Verfahren zur Ausfuhrung einer Transaktion zwi- 40 
schen einem lokalen Netzwerkknoten und einem 
entfernten Knoten in einem verteilten Datenbank- 
system, wobei der lokale Netzwerkknoten eine Be- 
nutzerschnittstelleneinrichtung (10) besitzt und der 
entfernte Knoten einen Datenbankmanager (34) fur 45 
eine entfernte Datenbank, auf die durch den ent- 
fernten Knoten zugegriffen werden kann ; besitzt, 
wobei das Verfahren die folgenden Schritte umfaRt: 

es uber die Benutzerschnittstelleneinrichtung so 
(10) einem Benutzer ermoglichen, eine Trans- 
aktion einzuleiten; 

einen Benutzer uber die Benutzerschnittstel- 
leneinrichtung (10) auffordern, Datenfelder mit 55 
Informationen einzugeben, die fur eine Reihe 
von Anfragen benotigt werden, die die Trans- 
aktion definieren; 



Ubertragen (48) der durch den Benutzer spezi- 
fizierten Informationsdatenfelder von dem loka- 
len Netzwerkknoten uber eine Netzwerkkom- 
munikationsverbindung (22, 26) zu dem ent- 
fernten Knoten als eine einzelne Nachricht; 

Reagieren auf den Empfang der einzelnen 
Nachricht an dem entfernten Knoten, wobei ei- 
ne Reihe individueller Datenbankanfragen 
uber den Datenbankmanager (34) unter Nut- 
zung der ubertragenen Informationsdatenfel- 
der durchgefuhrt werden (52, 54), um ein 
Transaktionsresultat zu erhalten; 

und Zuruckbringen (62) des Transaktionsresul- 
tats an den lokalen Netzwerkknoten als eine 
zweite einzelne Nachricht uber die Kommuni- 
kationsverbindung (22, 26). 

Verfahren, wie es in Anspruch 1 beansprucht wur- 
de, wobei die Informationsdatenfelder und Trans- 
aktionsresultate vor der Ubertragung uber die Netz- 
werkkommunikationsverbindung auf eine vorher 
ausgewahlte Weise formatiert werden (42, 56) und 
wobei die Informationsdatenfelder und die Transak- 
tionsresultate bei Empfang am entfernten bezie- 
hungsweise lokalen Knoten ruckgespeichert wer- 
den (50, 64). 

Verfahren, wie es in Anspruch 1 oder Anspruch 2 
beansprucht wird, wobei der Datenbankmanager 
ein SQL-Datenbankmanager ist und jede der Da- 
tenbankanfragen eine SQL-Anfrage enthalt. 

Verteiltes Datenbanksystem, bei dem eine Trans- 
aktion zwischen einem lokalen Netzwerkknoten 
und einem entfernten Knoten ausgefuhrt werden 
kann, wobei der lokale Netzwerkknoten eine Benut- 
zerschnittstelleneinrichtung (10) und der entfernte 
Knoten einen Datenbankmanager (34) fur eine ent- 
fernte Datenbank besitzt, auf die uber den entfern- 
ten Knoten zugegriffen werden kann, wobei der lo- 
kale Netzwerkknoten folgendes umfaGt: 

Mittel, um es einem Nutzer uber die Benutzer- 
schnittstelleneinrichtung (10) zu ermoglichen, 
eine Transaktion einzuleiten; 

Mittel, um einen Benutzer uber die Benutzer- 
schnittstelleneinrichtung (10) aufzufordern, 
Datenfelder mit Informationen einzugeben, die 
fur eine Reihe von Anfragen benotigt werden, 
die die Transaktion definieren; 

Mittel zum Ubertragen (48) der durch den Be- 
nutzer spezifizierten Informationsdatenfelder 
von dem lokalen Netzwerkknoten uber eine 
Netzwerkkomminikationsverbindung (22, 26) 
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zu dem entfernten Knoten als eine einzelne 
Nachricht. 

sowie der entfernte Knoten folgendes umfaGt: 

5 

Mittel zum Reagieren auf den Empfang der ein- 
zelnen Nachricht zur Erstellung (52, 54) einer 
Reihe individueller Datenbankanfragen uber 
den Datenbankmanager (34) unter Nutzung 
der ubertragenen Informationsdatenfelder, um 10 
ein Transaktionsresultat zu erzeugen; 

und Mittel zum Zuruckbringen (62) des Trans- 
aktionsresultats an den lokalen Netzwerkkno- 
ten als eine zweite einzelne Nachricht uber die is 
Kommunikationsverbindung (22, 26). 

Revendications 

20 

1. Un procede d'execution d'une transaction entre un 
noeud de reseau local et un noeud distant dans un 
systeme de base de donnees distribue, le noeud de 
reseau local ayant une ressource d'interface utilisa- 
teur (30) et le noeud distant ayant un gestionnaire 25 
de base de donnees (34) destine a une base de 
donnees distante accessible par rintermediaire 
d'une distance, le procede comprend les etapes 
consistant a : 

30 

permettre, via la ressource d'interface utilisa- 
teur (30), a un utilisateur d'initier une transac- 
tion; 

demander, via la ressource d'interface utilisa- 
teur (30), a I'utilisateur d'introduire des ele- 35 
ments d'information necessaires pour une se- 
rie de requetes definissant la transaction; 
transmettre (48) depuis le noeud de reseau lo- 
cal sur une liaison de communication de reseau 
(22, 26) vers le noeud distant, a titre de mes- 40 
sage unique, les elements d'information speci- 
fies par I'utilisateur; 

en reponse a la reception du message unique 
au noeud distant, etablir (52, 54) une serie de 
requetes de base de donnees individuelles, par 45 
rintermediaire du gestionnaire de base de don- 
nees (34), avec utilisation des elements d'infor- 
mation transmis pur generer un resultat de tran- 
saction; 

50 

et retourner (62) le resultat de transaction au noeud 
de reseau local a titre de deuxieme message uni- 
que sur la liaison de communication (22, 26). 

2. Un procede selon la revendication 1 , dans lequel 55 
les elements d'information et le resultat de transac- 
tion sont formates (42, 56) d'une maniere preselec- 
tionnee avant la transmission sur la liaison de com- 



munication de reseau, et dans lequel les elements 
d'information et le resultat de transaction sont reta- 
blis (50, 64) a la reception au noeud distant et au 
noeud local, respectivement. 

3. Un procede selon la revendication 1 ou 2, dans le- 
quel le gestionnaire de base de donnees est un ges- 
tionnaire de base de donnees SQL et chacune des 
requetes de base de donnees comprend une reque- 
te SQL. 

4. Un systeme de base de donnees distribue, dans le- 
quel une transaction peut etre executee entre un 
noeud de reseau local et un noeud distant, le noeud 
de reseau local ayant une ressource d'interface uti- 
lisateur (10) et le noeud distant ayant un gestion- 
naire de base de donnees (34) pour une base de 
donnees distante accessible par rintermediaire du 
noeud distant, le noeud de reseau local 
comprenant : 

des moyens pour permettre, via la ressource 
d'interface utilisateur (10), a un utilisateur d'ini- 
tier une transaction; 

des moyens pourfaire requete, via la ressource 
d'interface utilisateur (10) par I'utilisateur d'in- 
troduire des elements d'information necessaire 
pour une serie de requetes definissant la tran- 
saction; 

des moyens de transmission (48), depuis le 
noeud de reseau local, sur une liaison de com- 
munication de reseau (22, 26), au noeud dis- 
tant, a titre de message unique, des elements 
d'information specifies par I'utilisateur; 

le noeud distant comprenant : 

des moyens reagissant a la reception du mes- 
sage unique pour etablir (52, 54) une serie de 
requetes de base de donnees individuelles par 
rintermediaire du gestionnaire de base de don- 
nees (34) faisant utilisation des elements d'in- 
formation transmis pour generer un resultat de 
transaction; 

et des moyens de retour (62) du resultat de 
transaction au noeud de reseau local, a titre de 
deuxieme message unique sur la ligne de com- 
munication (22, 26). 
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